The session initiation protocol (SIP) is an internet engineering task force (IETF)-defined signaling protocol for controlling multimedia communication sessions, such as voice and video calls, over packet networks, such as networks that use the Internet protocol (IP). The SIP protocol is an application layer protocol designed to be independent of the underlying transport layer, which may be the transmission control protocol (TCP), the user datagram protocol (UDP), or the stream control transmission protocol (SCTP), for example. SIP is a text-based protocol. SIP can be used for creating, modifying and terminating sessions between two or more parties. A session may include one or more media streams. SIP has been accepted as a 3rd generation partnership project (3GPP) signaling protocol and is a key standard of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in fixed/mobile convergent (FMC) systems. SIP may be the underlying protocol for voice-over-IP (VoIP) service, which allows users to make telephone calls via a packet network such as the Internet rather than through the traditional public switched telephone network, or PSTN.
In one example, a home or small business may use VoIP as the primary (or only) means of telephone service. A home, for example, may have VoIP telephones in several different locations, e.g., separate telephones in the kitchen, den, parents' room, etc. In these scenarios, it is common that the home or small business is configured so that all VoIP telephones share the same SIP identity, in which case there are multiple devices, e.g., not only VoIP telephones but also softclients running on computers, tablets, smartphones, etc., that all register using the same SIP identity. FIG. 1 illustrates such a scenario.
FIG. 1 is a block diagram illustrating a conventional communication environment that includes multiple SIP devices having the same SIP identity. In FIG. 1, a home or office includes three SIP devices 100, 102, and 104 which register with a service node 110 and which communicate through service node 110 to the outside world. Each SIP device is associated with the same identity, which in the example illustrated in FIG. 1 is “userA@domain”. In this manner, all registered user devices that are associated with the same identity receive incoming call or session requests, analogous to the operation of traditional home telephones, where an incoming call causes all of the telephones in the house to ring.
However, there are limitations to this arrangement. Conventional service nodes such as service node 110 are configured with call management rules on a per-identity basis, not on a per-device basis. For example, service node 110 may be configured for call management rules, but these rules will apply uniformly to each of SIP devices 100, 102, and 104. Another limitation is that services provided by the service node apply equally to each SIP devices. For example, once an incoming call is answered by one of the SIP devices 100, 102, or 104, there is no mechanism to transfer the call or session to a specific device associated with the same identity. Yet another limitation is the granularity of reports. For example system call logs, such as those that may be maintained by service node 110, do not identify which of SIP devices 100, 102, or 104 placed or answered the call.
It would be desirable to provide systems and methods that would allow multiple SIP devices to continue to be associated with the same identity yet allow device-level management capabilities such as: per device call management rules, device-to-device transfer, and log files that identify which device was involved with which activity. Accordingly, there exists a need for systems, methods, and computer readable media for SIP device-level call/session/service management.